@rafael2k is the master branch the correct one to add new functionality and the one used by the ELKS' automatic builds?

@ghaerr I want to compile lua (which is compiled with owcc) together with libnano-X.a, but libnano-X.a is compiled with gcc ia 16. So is this actually possible?

@rafael2k is the master branch the correct one to add new functionality and the one used by the ELKS' automatic builds?

Very cool @toncho11 ! Yes, that is correct!

I want to compile lua (which is compiled with owcc) together with libnano-X.a, but libnano-X.a is compiled with gcc ia 16. So is this actually possible?

Files compiled with OWCC can't be combined/linked with IA16 objects, and vice versa; the object files themselves as well as the function calling conventions are incompatible.

A few options might be either an OWCC version of the Nano-X client library (libnano-X.lib) or an ia16-elf-gcc version of LUA. The Nano-X client library communicates with the Nano-X server via a UNIX socket, so only the client library files (microwindows/src/nanox/{client.c,nxproto.c,nxutil.c,osdep.c) need to be compiled and linked with the application object files. This may not be a big deal, but would require changes to Makefile.elks on the Nano-X repo, or compiling those files along with the LUA build.

The other method would compiling LUA in small model using ia16-elf-gcc. Is there a reason why LUA must be compiled large model? It would seem the cubes demo itself shouldn't require more than 64K code or data, but I haven't looked at the LUA engine to determine that.

I want to compile lua (which is compiled with owcc) together with libnano-X.a, but libnano-X.a is compiled with gcc ia 16. So is this actually possible?

Files compiled with OWCC can't be combined/linked with IA16 objects, and vice versa; the object files themselves as well as the function calling conventions are incompatible.

A few options might be either an OWCC version of the Nano-X client library (libnano-X.lib) or an ia16-elf-gcc version of LUA. The Nano-X client library communicates with the Nano-X server via a UNIX socket, so only the client library files (microwindows/src/nanox/{client.c,nxproto.c,nxutil.c,osdep.c) need to be compiled and linked with the application object files. This may not be a big deal, but would require changes to Makefile.elks on the Nano-X repo, or compiling those files along with the LUA build.

The other method would compiling LUA in small model using ia16-elf-gcc. Is there a reason why LUA must be compiled large model? It would seem the cubes demo itself shouldn't require more than 64K code or data, but I haven't looked at the LUA engine to determine that.

Yes - I chose the large model for compiling Lua for a reason.
: )
Just "vendor" these files @ghaerr mentions inside the ELKS Lua repository, if things work / if owcc compiles cleanly the nanoX source, it is a good first step.

So it did work!!!!!!!!!!!!!!!!!!!!!!!!! But there are also limitations ...

You need to set NANOX_DIR = in you Makefile.elks and we get the executable that supports Nano X.

Here are the details and limitations:

• it only worked when I did /bin/nanox & /bin/lua /root/drawcube.lua
• it did not work like this lua drawcube.lua, it gives an error that it can not open Nano-x
• I started nxdsktop and nxterm and tried from there, but guess what - it gives "lua:out of memory".

hd32-minix.zip

Actually the idea was to have it working from nxdsktop as a nice demo. But progress is made!!!!!!!!!!!!!!!!!!!

I reduced the speed between frames and I got a better screenshot

@ghaerr I tried these in the Lua makefile:

DEFINES += -DAUTO_START_SERVER=1
DEFINES += -DBIN_NANOX='"/bin/nano-x"'

but it did not enable lua ./drawcube.lua.

Maybe the fork that is done when calling it like this lua ./drawcube.lua requires too much memory to start nano-x? While /bin/nanox & /bin/lua /root/drawcube.lua avoids this?

This is very cool!! If memory turns out to be a problem, we can use an older Lua version (some branches here...) or just trim down some modules from ELKS Lua build.
ps: This branch uses less memory: https://github.com/rafael2k/lua/tree/lua-5.1

Maybe the fork that is done when calling it like this lua ./drawcube.lua requires too much memory to start nano-x? While /bin/nanox & /bin/lua /root/drawcube.lua avoids this?

It seems likely that's what's happening. The current fork->exec model for starting new processes with ELKS can fail when the calling process is large but there's still room in memory for the new process. I'm thinking perhaps ELKS should implement a posix_spawn system call, where the caller's memory is not required to be duplicated like fork, but instead a new process is created from scratch, then memory only allocated for the exec'd process.

When called from the system() C library routine, which is frequently the case, the situation gets worse since system() fork/execs /bin/sh -c ... in order to interpret possibly passed arguments, then the shell yet fork/execs another time for the requested program.

Getting the shell to use posix_spawn could be complicated, but for programs that just want to basically execute another process and skip any sh -c interpretation, an alternative system2() or similar library routine could be written that calls a new posix_spawn system call to enable running programs without using so much memory.

In particular, the Nano-X client library uses just fork/exec and could be enhanced to use posix_spawn instead.

There is already a fork optimisation using do_fork(1), but it is disabled: https://github.com/ghaerr/elks/blob/76a97d95eb923cf1a483409e7af226a62afb3c64/elks/kernel/fork.c#L158 ?

So parent and child share memory with do_fork(1) ? Can it be a possible solution?